Scaling DLC Part2: Free option problem with DLC

Paper:Discreet Log Contracts Channels and Integration in the Lightning Network
Scaling DLC series:
Scaling DLC Part1: Off-chain Discreet Log Contracts
Scaling DLC Part2: Free option problem with DLC -this post
Scaling DLC Part3: How to avoid free option problem with DLC
Scaling DLC Part4: Integrating DLC channels in the Lightning Network

In the previous post, I gave an overview of DLC transactions and mentioned the option problem with DLC. In this post I describe the details of this problem. If two parties execute consecutive contracts within a DLC channel, they need to revoke the transactions for the previous contract, to ensure that a malicious party does not try to close the channel at an old state. As an illustration, in Figure1, the transactions for the third trade need to be revoked after the transactions for the fourth trade are set up.

Figure 1. Consecutive contracts on DLC channels

A straw-man protocol
The simplified protocol between Alice and Bob when setting up the fourth trade and revoking transactions for the third one is described in Figure.2. They first exchange public keys used for the construction of the transactions for the fourth trade, as well as signatures for these transactions, before exchanging the secret values to revoke the transactions from the third trade (the revoking mechanism is the same as used in the Lightning Network and is described in BOLT #3)

Figure 2. A straw-man protocol between Alice and Bob

The problem
Assume that Bob refuses to respond to Alice after step 3 in Figure.2. Upon receipt of Alice’s message, Bob is able to broadcast both the transactions from the previous trade, as well as the ones from the most recent trade. Alice, on the other hand, has revoked the transactions from the previous trade, so she can’t broadcast them and can only broadcast the transactions for the latest trade after the oracle publishes a signature deciding the outcome of the contract. (Note that she can’t broadcast anything prior to the oracle publishing a signature ). On the other hand, Bob has the option to either close the previous trade, or the latest one after the Oracle publishes a signature.
We call that the “free option” problem (Don’t be confused with the free option problem of atomic swaps)

Why do the Lightning Network payments not have the free option problem?
Note that Lightning Network payments do not have this problem. In Lightning Network payments there is a sender and recipient. Since the latest state is more profitable for the recipient than the previous one, the recipient has no incentive to close the channel at the previous state.
On the other hand, DLC players don’t know which trade will be more favorable to them when updating the channel state.Therefore, the malicious party will be able to keep both the previous transaction and the most recent transaction and choose the one that is likely to be advantageous to him.
Here’s an overview of the mechanism of revocation between senders and recipients of Lightning Network.

In the next post, I will explain how to avoid the free option problem with DLC channels.